home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Hackers Underworld 2: Forbidden Knowledge
/
Hackers Underworld 2: Forbidden Knowledge.iso
/
VIRUS
/
VDETECT.TXT
< prev
next >
Wrap
Internet Message Format
|
1990-09-27
|
14KB
From: jmolini@nasamail.nasa.gov (JAMES E. MOLINI)
Date: Wed, 4 Apr 90 14:03 PDT
Message-Id: <LJJA-2875-5674@nasamail>
To: virus-l@ibm1.cc.lehigh.edu
Cc: rdavis@nasamail.nasa.gov, lsnapp@nasamail.nasa.gov
Subject: Universal Virus Detector?
X-Lines: 272
I am working with a colleague on defining a robust virus detection
utility. The paper below discusses an approach we are investigating.
The work was undertaken as part of a research project sponsored by the
National Aeronautics and Space Administration at the Johnson Space Center.
Please look it over and tell us what you think. We would like to know what
type of virus could be written to defeat this type of detector on a large
scale. I know it is a rather long document, but you might find it
interesting. Thanks in advance.
A Universal Virus Detection Model
by Chris Ruhl and James Molini
Computer Sciences Corp.
Email: jmolini@nasamail.arc.nasa.gov
PREFACE
This paper attempts to define an abstract model which will support the
construction of a Universal Virus Detector. Although the restrictions
imposed upon the model for 100% accuracy may be too severe to make such
an implementation practical, it is quite feasible to achieve near
universal virus detection in a user friendly fashion.
This paper is distributed with the intent of discovering reasonable
vulnerabilities in the concepts, or implementation. Comments are
therefore encouraged. We have used an IBM PC Compatible running MS DOS
3.X as the candidate implementation platform for convenience.
The paper does not discuss virus identification, which is a separate
issue from detection. Although not "absolutely necessary," virus
identification mechanisms dramatically reduce the time required to
eradicate specific cases of virus infection.
If you have questions, or see a flaw in the process, please let us
know. We are building a virus detector, which could be placed into the
public domain, that uses the techniques below to detect virus
infections. Our initial tests have shown encouraging results.
Please send comments/suggestions to Virus-L, or the authors at the
Email address above. Please do not request code samples, or testing
opportunities until we announce availability of the utility.
Definitions
Before proceeding with our discussion, it is important to define
terms. The following definitions are taken (as faithfully as possible)
from the most recent discussions about viruses on the various Email
networks:
VIRUS - A self-replicating program that must attach itself in some way
to an existing executable on the target computer system in order to
propagate. In doing so, no overt user action is required to further
the replication process.
TROJAN HORSE - A non-replicating malicious program that misleads the
user in order to cause him/her to execute it's malicious code.
Although it is malicious code, it is often hidden inside another piece
of (apparently innocuous) code in order to escape detection. This type
of program does not modify any existing executable files on the system.
WORM - A self-replicating program that does not attach itself to other
executable code in order to propagate. It relies upon some weakness in
a multi-user system, or requires some sort of overt user action in
order to operate. The technical feasibility of worms on single user
computer systems is debatable.
INFECTION - The act of modifying existing executable code in order to
propagate a virus.
MASKING - The act of preventing discovery by intervening at some point
in the scanning process. Typically this effects an indication of a
clean system, when, in fact, the environment under review has been
modified.
Understanding the scope of the virus problem, it is possible to define
a circumstance in which a Universal Virus Detector (UVD) may be
successful. We further scope the problem by NOT requiring that the UVD
prevent an infection. Instead it can identify an infection after it
has occurred. This principle is similar to the idea that smoke
detectors are not responsible for preventing fires, although they may
periodically work toward that end. They are actually responsible only
for responding to indications that a fire may be present and warning
the user of impending danger. UVD's must be scoped to a similar
purpose for them to work.
With this in mind, let us begin by defining the physic of computer
viruses:
A Virus Propagation Model
Although a Virus is an abstraction (i.e. Program), the environment
it attacks is not (i.e. IBM PC). Regardless of how creative the author
is, he/she cannot change certain characteristics of the machine that
the Virus inhabits. In order to develop this model the following
assumptions are made:
a.) The user will begin the detection process (we have proposed a
CRC type routine) prior to infection. By doing so, the user
has provided an uninfected baseline from which to judge future
states. Although virus propagation may still be identifiable
on an infected machine, the level of detection for subsequent
states becomes indeterminate.
b.) The user will avoid the introduction of self modifying code
into the system. By doing so, he/she ensures that the target
system maintains a given state of integrity.
Given the assumptions above, we may now define the circumstances
necessary to support a virus infection. Without the adherence to the
following rules, it is impossible to define a circumstance in which a
virus can propagate.
Rule #1: A Virus infection, or propagation occurs when an
executable file is altered.
Proof:
I) An un-altered executable will not be infected since by
definition it is not altered. Here we are assuming that the
original state of the machine is uninfected.
II) An unaltered piece of code that performs malicious acts is a
Trojan horse and thus, beyond the scope of this problem.
III) A non-executable file, whether altered, or not, cannot
further infect the system since by definition it is never
executed. An altered non-executable is merely a damaged data
file.
Thus: Only altered executables can further infect the system.
Note: In certain cases, a new executable file can be added to the
system, but it still cannot infect the system, unless it is
called from a modified file in the system, (violating I
above) or unless the user intervenes, in which case the
program is not a virus, but a worm, or Trojan Horse.
Rule #2: Assuming that the detection mechanism is sufficiently
robust, the only possible way to avoid detection is to
mask the infection prior to having the detection results
presented to the user.
Proof:
I) An un-altered procedure cannot mask an infected file since
by definition its not altered to do so. (Masking requires
foreknowledge of the code to be masked. Such a masking
scenario would indicate a state of infection prior to
installation of the UVD violating a basic assumption that you
install it on a clean machine.)
II) Masking requires some type of intervention in the file
read/result presentation process. Here we assume that the
computation of the checksum is sufficiently robust that no 2
different pieces of code can generate the same result.
Therefore, since masking requires some type of modification
of data in the path from storage to user and since the only
2 feasible parts to that path are either the read, or the
delivery, any masking must be completed at one of the 2 ends
of the pipe.
Thus: Only altered procedures can mask the infection of
executables.